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Abstract: 

The improving computational performance of PCs and the near real-time response of PC operating 
systems now make it feasible to implement reasonable performance HF ARQ messaging protocols 
suitable for digital messaging. While Pactor (I, II, II) currently dominate and generally represent the 
best available performance, PC sound cards with appropriate DSP software can now begin to approach 
Pactor performance at lower cost than dedicated hardware HF modems. This paper covers the on-going 
development of an optimized sound card mode WINMOR, compatible with the popular Winlink 2000 
message system'*”. This effort leverages a prior feasibility project by the author in the evaluation of 
SCAMP*%, an adaptation of RDFT for digital messaging systems. The paper reviews the development 
effort of WINMOR (WINIink Message Over Radio) from motivation through tool development, 
programming, testing and deployment in the WL2K system. 
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Motivation: 

The PC, widely available DSP tools, well designed sound card/radio interfaces and improving amateur 
software skills have yielded a variety of sound card modes over the last several years. These modes 
range from simple DSP/software implementation of RTTY through complex streaming applications like 
Win DRM. It is one of the few remaining areas where amateurs can and do experiment. Many of the 
modes developed however are a replacement of existing “chat” modes or “broadcast” modes where 
absolute accuracy is not a requirement or data is limited to plain ASCII text. Today, however, a viable 
message system (with the need for compression and binary attachments) requires true “error-free” 
delivery of binary data. To achieve this there must be some “back channel” or ARO (Automatic Retry 
reQuest) so the receiving station can notify the sender of lost or damaged data and request 
retransmission or repair. HF Pactor (I, II, IID) has served us well in this regard providing good 
performance (net bits/sec/ Hz bandwidth) and robustness. However the proprietary nature of high 
performance Pactor modems (Pactor II, III) can be cost prohibitive especially in applications such as 
emergency communications where wide deployment coupled with low average usage make it difficult t 
justify the investment in high performance but costly hardware. As developers of Winlink 2000 we are 
continually asked to supply a lower cost of entry than Pactor for those needing to access the WL2K 
system on HF. 


Requirements for a Sound Card Mode for Digital Messaging: 

Based on the hundreds of requests that begin “Why don’t you just use PSK31?’ it appears there is a 
large gap in understanding the unique requirements a digital message system demands of a suitable 
sound card mode. 
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Table 1 lists what I call absolute requirements (needed to work) and desirable requirements (needed for 
efficiency) for a viable sound card mode suitable for a message system. 


Absolute Requirements Desirable Requirements 
Work with standard HF (SSB) radios Modest CPU & OS demands 
Accommodate Automatic Connections Bandwidth options (200, 500, 3000 Hz) 
Error-free transmission and confirmation Work with most sound cards/interfaces 


Fast Lock for practical length ARQ cycles | Good Bits/sec/Hz performance ~ P2 goal 


Auto adapt to a wide range of changing Efficient modulation and demodulation for 
channel conditions acceptable ARQ latency 
Must support true transparent binary to Selective ARQ & memory ARQ to 
allow attachments and compression maximize throughput and robustness. 
Must use loosely synchronous ARQ timing | Near Pactor ARQ efficiency (~70% of Raw 
to accommodate OS and DSP demands. theoretical throughput) 

Table 1. Sound Card Mode Requirements for a message system 


Perhaps the most challenging of these requirements are 


1) The ability to quickly tune, lock and acquire the signal which is necessary for practical 
length ARQ cycles in the 2-6 second range. 
2) The ability to automatically adapt the modulation scheme to changing channel 


conditions. An excellent example of this is Pactor III’s extremely wide range of 
speed/robustness (18:1) and is one reason it is such an effective mode in both good and 
poor channel conditions. 


The Tool Bag: 

Developing a new mode that meets the above requirements is challenging and to truly engineer a 
solution we have to organize and develop a set of tools and procedures that advance the process beyond 
simple build-and-try experiments. Luckily there are some good and fairly inexpensive aids for doing 
this. Here are some I have found to be valuable references, programs and equipment. 


Text and references: There is no substitute for good references on digital modulation. You’ll also need a 
good understanding of DSP theory along with some of the tricks and techniques of using DSP to 
implement the encoding/decoding of the sound card data. Two excellent reference texts are shown at the 
end of the paper **. 


Characterizing sound cards: You will also probably need a mechanism to quantify the performance of a 
sound card. One of the biggest challenges is achieving the required accuracy with the modest hardware 
(sometimes pretty poor hardware!) often found in PC sound cards. Professional DSP HF Modems 
usually contain very accurate and stable (short term jitter and drift) TCXO reference oscillators...PC 
sound cards might have a low quality $.50 crystal that may be as much as .5% off frequency. I used 
WWV’s tone bursts with available software like HamScope ’ to measure the sample accuracy and drift 
of several sound cards. 
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Wave File editors, converters and utilities: The only way to measure the effectiveness of certain 
algorithms is to be able to repeat tests with exactly the same sound card data. This requires working 
from a .wav file instead of “live” captured data from the sound card/radio or channel simulator. This 
also requires building development aids to capture sound card data and convert to one of the standard 
.WAV formats. I found the WAV MP3 Converter ° is a useful utility to convert wav file sampling rates 
and formats. 


DSP and FIR Design utilities: It is often necessary to analyze intermediate data in both the time and 
frequency domains (e.g. bandwidth, phase detection, S/N etc). A program called ScopeDSP” and 
another called ScopeFIR'® for FIR design proved to be quite useful during development. 


HF Channel Simulation: This is probably THE most important and most used tool. While over the air 
testing and experimentation can be fun, to really engineer a mode requires being able to repeat and 
compare measurements in known standardized and repeatable channels. There are two approaches and 
each has its advantages and limitations. I used both a hardware (DSP based) channel simulator’! and a 
software program’ that created wave files. Generally testing was done over a range of S/N values acros: 
4 standard CCIR channels. 


Candidate Modulation Schemes: 

In deciding on which modulation and ARQ schemes are appropriate for a message based HF ARQ 
sound card mode one has to trade off many often conflicting requirements. Some of these stem from a 
need/desire to maintain a certain bandwidth so we can efficiently and legally use the mode in the 
specific band segments allocated for digital. Even if we eventually migrate to a simpler “segmentation 
by bandwidth” scheme we still will likely require modes that fit within specific bandwidth requirements 
such as the 200, 500 and 3000Hz segments currently being debated. Also current HF requirements in the 
US limit us to a symbol rate of 300 symbols per second and that rules out some of the more 
sophisticated channel equalizing higher baud rate modems such as higher performance MIL STD- 
188/STANAG protocols. For WINMOR I investigated several PSK, FSK and QAM type modulation 
schemes comparing parameters like ease of modulation, demodulation, spectral efficiency, throughput, 
robustness and the ability to be easily configured to adapt dynamically to various channel conditions. 
Much can also be learned from studying the effective techniques used in some of the more complex 
ARQ modes like P2, P3 and Clover. Another important requirement of a message system is to minimize 
the “RF Footprint” which is the spectrum “area” (bandwidth x time) required to send a typical message. 
Figure 1 shows a comparison of some popular modes plotting their spectral efficiency (Bits/sec/Hz). For 
proper comparison all values were calculated with the same ARQ overhead at their maximum data rate 
(what might be approached on a good channel). While many of us are familiar with the robustness of 
modes like MT63 the chart clearly shows that Pactor 2 and 3 with their ability to dynamically adapt to 
channel conditions are the clear winners yielding the smallest RF footprint. 
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Comparison of Some Popular Mades In ARQ Environments 
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(After ARQ overhead) 
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HF Packet |< 
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Assumptions: 

1) 70% ARO efficiency (typical of Pactor) 

2) Max RAW data rate (good channel assumed, no FEC) 
3} 200 Hz guard band (allows automatic connections) 


Figure 1. Comparison of popular mode spectral efficiency in an ARQ protocol. 


During a number of initial evaluation tests the use of low baud rate multi carrier OFDM PSK proved 
both a theoretical and practical advantage over other schemes. The low baud rates (typically < 100 
baud) allows operation in typical HF multipath channels without the need for complex dynamic channel 
equalization. 


The ability to dynamically adjust the modulation scheme (e.g. BPSK, QPSK, 16PSK, 16QAM etc.) 
allows building a mode that is near constant bandwidth and can run at high speed in good conditions yet 
has the needed robustness when combined with significant FEC during poor channel conditions. A 
detailed spread sheet was constructed to compare various OFDM PSK and QAM schemes and ARQ 
framing cycles to compute the true net throughput after all ARQ overhead. Table 2 summarizes some of 
the candidate modes that were evaluated for WINMOR 62.5 baud PSK/QAM at 200 Hz and 500 Hz 
bandwidths and their relative performance. 


Mode BW(Hz) | #Car | Raw bps/Hz | ARQ Thruput | ARQ Cycle 
BPSK | Car 62.5 Short | ~ 190 1 33 23 bps 2.76 sec 
QPSK 1 Car 62.5 Short | ~ 190 1 .66 51 bps 2.51 sec 
QPSK 1 Car 62.5 Long | ~ 190 1 .66 92 bps 5.58 sec 
16QAM 1 Car 62.5 Long | ~ 190 1 1.32 188 bps 5.45 sec 
BPSK 3 Car 62.5 Short | ~ 470 3 40 69 bps 2.76 sec 
QPSK 3 Car 62.5 Short | ~ 470 3 .80 153 bps 2.51 sec 
QPSK 3 Car 62.5 Long | ~ 470 3 .80 275 bps 5.58 sec 
16QAM 3 Car 62.5 Long | ~ 470 3 1.60 563 bps 5.45 sec 


Table 2. Some candidate OFDM PSK/QAM modes and net ARQ performance 


This data shows that over a given bandwidth of say 500 Hz we can achieve a fairly wide throughput 
range of over 8:1 before FEC considerations. Typically FEC is then applied to expand the 
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speed/robustness range to 16:1 or more (for comparison the speed/robustness range in Pactor I is 2:1, 
Pactor II is 8:1 and Pactor III is 18:1). This wide range and the ability for the receiving station to detect 
the modulation mode and coding from the signal header itself (no a priori knowledge) is key to 
effectively and efficiently varying the modulation/encoding based on the dynamic channel quality and 
error history. 


Another very important advantage of the OFDM PSK/QAM modulation scheme is the efficiency of 
modulation and demodulation using the IFFT and FFT algorithms. This is important in an ARQ system 
as modulation or demodulation processing times over a few hundred ms begin to significantly impact 
throughput or require much more complex ARQ pipelining. 


Developing the DSP, control code and protocol. 

The bulk of the development effort consists of designing, debugging and optimizing the modules that 
implement the basic encoding (including FEC as required), modulation, demodulation and decoding. 
The PC based floating point DSP processing (primarily FFT, IFFT, Mixing, Hilbert Transform, 
correlation and FIR Filtering) form the bulk of the processing functions and are reasonably straight 
forward. In practice equally challenging efforts include other critical functions such as tuning, signal 
acquisition and tracking especially in very weak S/N or poor multipath channel conditions. While the 
basic techniques are well understood there is considerable work involved in iterating and tweaking of 
the required processing modules to minimize latency and provide good performance. Figure 2 is a flow 
diagram showing the major DSP processes required for WINMOR for both the transmit channel or ISS 
(Information Sending Station) and the receive channel or IRS (Information Receiving Station). For 
simplicity, details of the ARQ back channel are omitted but are similar to the forward channels but with 
lower data rates and increased robustness. Of particular note is the challenge to compute the ISS forward 
channel (from receipt of ARQ Ack/Nak to transmitting the next frame .wav file) in something less than 
about 200 ms. Also to minimize the receive channel latency, demodulation and decoding are done using 
a DSP pipeline where the first data symbols are captured, demodulated and decoded before the frame 
has been totally received. This also minimizes the effect of sound card/capture buffer latency due to the 
OS. The half duplex nature of the ISS and IRS channels means the DSP processing for ISS and IRS do 
not need to be done concurrently on the same computer. As in all ARQ system the IRS and ISS 
exchange rolls during the forwarding session base on interlocked “Over” and “Break” control frames. 
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Receive Channel (IRS) 
Figure 2. Data flow and DSP Processing summary WINMOR 


In addition to the heavy computational DSP development efforts there is also the necessary and 
important task of accurately documenting the WINMOR protocol, timing and data encoding details in a 
complete protocol specification. This “living” specification document serves a very important 
organization and discipline function during development as well as providing the baseline for the 
required public documentation of the mode and protocol once the mode 1s deployed. The goal is a final 
document that allows someone skilled in the DSP art to be able to duplicate the protocol and its 
implementation using the detailed public specification. 


Performance Targets and Measurement Approach 

The ultimate test of any digital mode is how well it works across good, poor and typical channel 
conditions. The best way to measure this is the end-to-end throughput of large files sent through an HF 
channel simulator using the final Client/Server software. Using large files eliminates aberrations in the 
measurements that could be caused by message level protocol and link turn over issues. It is also 
important to select a standardized measurement approach using agreed CCIR channel models across a 
number of S/N ratios. Figure 3 is a simplified block diagram showing the setup used for throughput 
measurements. These measurements were all performed using the Oregon Hardware — Software Factory 
HF channel simulator.'! 
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Testing the Protocol with the 
HF Channel simulator 


Station 2 
omputer & SignalLink USB Sound Card 
Modified PaclinkMP Client 


Station 1 
omputer & SignalLink USB Sound Card 
Modified PaclinkMP Client 


SC In 


Channel Options: 
Audio In Audio Out S/IN-5, 0, 5, 10, 15 dB 
Multi path: 
Oregon LEE REE? Software Good, Fair, Poor 
HF Channel Simulator Flat Fading: 
(used in both directions) Moderate, Severe 
RS232 
Flutter 


Figure 3. Protocol Testing Setup using HF Channel Simulator. 


While the HF simulator generates pseudo random channel disturbances (frequency selective fading, 
frequency shift, white noise etc) it yields test results which are quite repeatable and representative when 
averaged over several minutes and multiple channel scenarios. At the time of this writing (before 
integration of WINMOR into true clients and servers...see next section) it was not possible to complete 
the end-to-end tests through the channel simulator. However based on the initial BER measurements 
done across the same standardized channels during the evaluation of candidate modulation schemes it 
appears the new WINMOR should approach Pactor II in throughput. This is not surprising since both 
modes are 500 Hz BW modes employing multi PSK. Figure 4 shows the actual measured performance 
of P1, P2 and P3 and the expected throughput of WINMOR 500 Hz mode. 

WINMOR (500Hz mode) Targets P2 Throughput Performance 
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Figure 4. WINMOR (500Hz) Performance Target Compared to Pactor 
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Deploying for real Over-the-Air Testing: 

Once the required modules have been developed, optimized and tested on a channel simulator its time to 
integrate them into practical client and server radio email applications. The WL2K system with its multi 
protocol radio client (Paclink MP) and Radio Message Server (RMS) software provides an existing 
proven framework along with an active user base for testing WINMOR in a true message system 
environment. Since WINMOR implements true 8 bit transparent binary and has link turnover parameters 
generally similar to Pactor it can fairly easily be implemented as an add-on driver to the existing Pactor 
client and server modules. This allows seamlessly adopting WL2K’s efficient B2 protocol which 
provides significant compression gain for most data types. For example adding the required sound card 
interface, DSP and protocol processing code allows WINMOR to be readily integrated into the existing 
RMS Pactor Server. To do this requires developing the required WINMOR driver with program 
interfaces similar to the Pactor driver and then providing menus that allow the sysop to designate 
WINMOR “channels” in addition to existing Pactor “channels”. This also allows time-sharing some of 
the major and more expensive components (radio, tuner, antenna, and computer) with existing Pactor 
channels. 


Summary: 

Developing a new sound card mode for a messaging system from the ground up is a challenging task but 
what is required to approach the performance of well established hardware modes such as Pactor. By 
identifying the specific requirements, demands and limitations and then adapting proven modulation 
modes and DSP techniques we can now begin to approach the performance of high-end hardware 
modems with their dedicated high-performance DSPs. The successful development and deployment of 
new modes such as WINMOR into a fully capable radio email system should open up new applications 
and significantly lower the cost of entry. 
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